Summary

Builds on the manual release workflow from ARSN-604 (#2656): on release, build and dual-publish @scality/arsenal to GitHub Packages and npmjs. arsenal is a public, Apache-2.0 library, so per the DevEx TAD it goes to both registries. Non-breaking — existing git-dependency consumers (cloudserver, backbeat, vault2) are untouched; migrating them to the registry is a later, organic step.

release.yaml is split into jobs so the build is produced once and each publish can be retried independently of it and of the other:

• build — after the branch / version / tag guards: install, yarn build, npm pack, generate a signed build-provenance attestation for the tarball (actions/attest-build-provenance), and upload the .tgz as the artifact.
• publish-github — download the tarball and publish it to GitHub Packages with the built-in GITHUB_TOKEN.
• publish-npm — publish the same tarball to npmjs via OIDC trusted publishing (id-token: write, no stored token) with --provenance.
• release — create the GitHub release + tag, linking to both packages.

Both publish jobs use the committed package.json version (no auto-bump), check the registry with npm view first and skip if that version is already published — so a partial dual-publish can be re-run cleanly — and publish under a v<major.minor> dist-tag so an older release line never moves latest. Building and packing once, then attesting and publishing the same tarball to both registries, gives a single GitHub attestation (gh attestation verify <tarball> --repo scality/Arsenal) covering whatever lands in either registry, plus npm-native provenance on npmjs.

Name: committed, not stamped

package.json is renamed to @scality/arsenal directly — no publish-time name stamp / jq. Git-dependency consumers resolve arsenal by their dependency key, not the package's name, so committing the scoped name keeps require('arsenal') working for cloudserver/backbeat/vault2 (verified end-to-end: real arsenal committed as @scality/arsenal, consumed under the unchanged bare arsenal git key, installs to node_modules/arsenal and resolves both bare and deep arsenal/build/... imports). package.json also drops private and adds types/files + publishConfig.access: public. The version stays committed / manually bumped — auto-stamping is deferred to a later step.

The workflow tests under tests/workflows stub the publish path, so the guard coverage is unchanged.

Prerequisite (npmjs trusted publishing)

The npm publish uses OIDC trusted publishing — no NPM_TOKEN. Before the first npm release, a trusted publisher must be registered for @scality/arsenal: GitHub org scality, repo Arsenal, workflow release.yaml (the same setup Sylvain did for @scality/cloudserverclient). Since @scality/arsenal isn't on npm yet, bootstrap it one of two ways:

• One-time manual publish by anyone with @scality publish rights (yarn build && npm publish --access public) to create the package, then register the trusted publisher. That first version has no provenance (local publish); the workflow provenance-signs every release after it and skips the bootstrapped version via its npm view check.
• Org-level trusted publishing, if the @scality npm org allows creating packages via OIDC — then the first workflow run creates it, no manual step.

GitHub Packages needs no bootstrap (built-in GITHUB_TOKEN).

Aligned with the DevEx initiative (S3C-9725); mirrors the dual-publish model of hdclient / cloudserverclient.

Issue: ARSN-605